An Observation-Based Middlebox Policy Taxonomy

peer reviewedRecent years have seen the rise of middleboxes, such as NATs, firewalls, or TCP accelerators. Those middleboxes play an important role in today's Internet, including enterprise networks and cellular networks. However, despite their undisputable success in modern network architecture, their actual impact on packets, traffic, and network performance is not that much understood. In this paper, we propose a path impairment oriented middlebox classification that aims at categorizing the initial purpose of a middlebox policy as well as its potential complications

Towards a Closed-Looped Automation for Service Assurance with the DxAgent

peer reviewedRecently, Intent-Based Networking (IBN) has known an increasing interest from both the industry and research communities. IBN comes with the advantage of easily expressing the desired state of a network. In parallel, service assurance, through observability, has been becoming more prevalent to maximize the business continuity. In that spirit, Service Assurance in Intent-based Networking (SAIN), is under standardization at the IETF and proposes a general framework towards closed-loop automation for service assurance. This paper introduces the Diagnostic Agent (DxAgent), an open-source SAIN implementation whose purpose is to determine symptoms and health levels of the different subservices of a network service. As such, the DxAgent appears as a first step towards closed-loop automation for service assurance. This paper describes the DxAgent implementation and demonstrates its efficiency through use cases.Closed Loop Automation for Service Assurance in a Virtualized DataplaneApplication-oriented Infrastructure Observation and Assurance (AoIOA) at the EdgeCYBEREXCELLENCE Le projet d’excellence de la cyber sécurité dans le cadre du plan de la Région Wallonne (CyberWal

Characterizing and Modeling of Transport-Based Middleboxes

It is now acknowledged that the initial end-to-end paradigm of the TCP/IP architecture,where both participants in a communication would assume that all exchanged information addressed to the other participant would remain untouched in-transit, has come to an end. This evolution was caused by the progressive introduction of middleboxes, i.e., network appliancesmanipulating traffic for purposes other than packet forwarding, going from “simple” NATs to complex multi-policy traffic engineering systems that alter packets up to the application layer. Today, middleboxes are present in increasing numbers, in various kind of networks. In enterprise networks, they are reported to be as numerous as traditional network equipment]. In cellular networks, they are strategically positionned and used for various purposes (e.g.,Carrier-Grade NATs, Traffic Engineering). In home networks, they are ubiquitous, as most Customer-Premise Equipments (e.g., Home Gateways) are middleboxes. Moreover,with the increasing popularity of Network Function Virtualization (NFV) and of virtualization technologies (i.e., hypervisors, containerization, orchestrators), middlebox development and deployment is facilitated. Regrettably, middleboxes have also been shown to engender multitude of connectivity, performance, and security issues. Establishing TCP connections with Explicit Congestion Notification (ECN) enabled can lead to connectivity blackouts. Mobile carriers using middleboxes to impose aggressive timeout value for idle TCP connections increase mobile devices battery consumption. Careless TCP middleboxes can facilitate certain network attacks, and even bring new attack vectors. Furthermore, middleboxes have a negative impact on the TCP protocol, by hindering its evolution. They may modify, filter, and drop packets that do not conform to their own policies and assumptions. For instance, they may normalize TCP flows to conform to the restricted set of authorized features of their choice, hampering TCP innovation initiatives. Generally speaking, we are witnessing the ossification of the network infrastructure. Alternative transport protocols that do not rely on TCP nor UDP, such as the Datagram Congestion Control Protocol (DCCP) or the Stream Control Transmission Protocol (SCTP), despite being standardized, fail to be deployed at large scale. The situation of the application layer is similar, with HTTP being the de-facto standard. This apparent antagonism between innovation and network value is the reflect of that between the Internet stakeholders. Middleboxes are unilaterally deployed to fulfill manufacturers or network provider short-term commercial goals, while path transparency advocators have for only purpose to improve the Internet in the long-term. Because of this ongoing contention, researchers have to find devious way to produce innovation. To overcome this, protocol designers have to ensure the middlebox-proofness of their solution. For example, recent discussions lead to the choice of UDP as a lightweight substrate for new protocols. Google’s Quick Internet Connections (QUIC), currently used by Chrome browser, is a famous example of UDP-based protocol. It incorporates a multiplexed stream transport over UDP and its own application-level transport. The design of the MultiPath TCP (MPTCP) feature, also required dedicated efforts to consider all possible in-path tampering and avoid unforeseen middlebox impairments. In this thesis, we study the transport-layer ossification, we propose an intermediate classification of its factors, and we study a de-ossification strategy. First, we evaluate the feasability of UDP encapsulation to re-enable transport evolution. We show that differential treatment based on UDP wire image is not problematic, but requires fallback strategies. Second, we characterize middlebox deployment in the wild. From a dataset collected from a large-scale campaign of active probing, we extract observations of in-path packet manipulations that we process to highlight the responsible middlebox policies and the path condition that they engender. We categorize the obtained middlebox-induced path impairments based on the potential negative consequences that they create on TCP traffic, and we use the resulting classes to give insights on the deployment and prevalence of path-impairing middleboxes in the wild. In particular, we show that a substantial percentage of network paths are affected by feature or protocol-breaking middleboxes and that they are in majority located in the edge networks. We advocate for protocol designers to include a fallback mechanism carefully designed to ensure robustness to the classes of middleboxes described in this thesis. Finally, we elicit a generic model of transport-level middlebox policies, that we implement in a high-speed kernel-bypass framework. Then, we rely on the latter to replicate existing path impairments, in a controlled environment, that we leverage to study how middleboxes affect TCP Quality-of-Service

copycat: Testing Differential Treatment of New Transport Protocols in the Wild

peer reviewedRecent years have seen the development of multiple transport solutions to address the ossification of TCP in the Internet, and to ease transport-layer extensibility and deployability. Recent approaches, such as PLUS and Google's QUIC, introduce an upper transport layer atop UDP; their deployment therefore relies on UDP not being disadvantaged with respect to TCP by the Internet. This paper introduces copycat, a generic transport protocol testing tool that highlights differential treatment by the path in terms of connectivity and QoS between TCP and a non-TCP transport protocol. copycat generates TCP-shaped traffic with custom headers, and compares its performance in terms of loss and delay with TCP. We present a proof-of-concept case study (UDP vs. TCP) in order to answer questions about the deployability of current transport evolution approaches, and demonstrate the extent of copycat's capabilities and possible applications. While the vast majority of UDP impairments are found to be access-network linked, and subtle impairment is rare, middleboxes might adapt to new protocols that would then perform differently in the wild compared to early deployments or controlled environment testing

Towards a middlebox policy taxonomy: Path impairments

peer reviewedRecent years have seen the rise of middleboxes, such as firewalls, NATs, proxies, or Deep Packet Inspectors. Those middleboxes play an important role in today's Internet, including enterprise networks and cellular networks. However, despite their huge success in modern network architecture, they have a negative impact on the Internet evolution as they can slow down the TCP protocol evolution and its extensions. Making available a summary of the potential middlebox network interferences is of the highest importance as it could allow researchers to confront their new transport protocol to potential issues caused by middleboxes. And, consequently, allowing again innovation in the Internet. This is exactly what we tackle in this paper. We propose a path impairment oriented middlebox taxonomy that aims at categorizing the initial purpose of a middlebox policy as well as its potential unexpected complications. Based on a measurement campaign on IPv4 and IPv6 networks, we confront our taxonomy to the real world. Our dataset is freely available

Using UDP for Internet Transport Evolution

The increasing use of middleboxes (e.g., NATs, firewalls) in the Internet has made it harder and harder to deploy new transport or higher layer protocols, or even extensions to existing ones. Current work to address this Internet transport ossification has led to renewed interest in UDP as an encapsulation for making novel transport protocols deployable in the Internet. Examples include Google's QUIC and the WebRTC data channel. The common assumption made by these approaches is that encapsulation over UDP works in the present Internet. This paper presents a measurement study to examine this assumption, and provides guidance for protocol design based on our measurements. The key question is "can we run new transport protocols for the Internet over UDP?" We find that the answer is largely "yes": UDP works on most networks, and impairments are generally confined to access networks. This allows relatively simple fallback strategies to work around it. Our answer is based on a twofold methodology. First, we use the RIPE Atlas platform to basically check UDP connectivity and first-packet latency. Second, we deploy copycat, a new tool for comparing TCP loss, latency, and throughput with UDP by generating TCP-shaped traffic with UDP headers

Antropološka analiza staroslovanskega grobišča Dlesc pri Bodeščah

The Internet is full of middleboxes that change packets and flows. In fact, there is probably no IP or TCP header that is not affected by at least one middlebox. Obviously, middleboxes impede path transparency, i.e., the idea that an exchange of messages results in more or less the same packets, no matter what path the packets takes. But no one seems to have a truly global view of what middleboxes do to packets on what Internet paths, which would however be an essential knowledge for new transport protocols to be successfully deployed. We address these concerns in the MAMI project by building an observatory of path transparency measurements. The project hosts an extensive set of path transparency measurements – we believe it to be the first dataset to deal specifically with middlebox involvement. In this paper, we describe that Observatory and a number of questions that we want to address with the data in that Observatory. Eventually, the project will provide public access to that Observatory so that researchers and the interested public can ask their own questions about path transparency issues and middlebox involvement

Using UDP for Internet Transport Evolution

The increasing use of middleboxes (e.g., NATs, firewalls) in the Internet has made it harder and harder to deploy new transport or higher layer protocols, or even extensions to existing ones. Current work to address this Internet transport ossification has led to renewed interest in UDP as an encapsulation for making novel transport protocols deployable in the Internet. Examples include Google's QUIC and the WebRTC data channel. The common assumption made by these approaches is that encapsulation over UDP works in the present Internet. This paper presents a measurement study to examine this assumption, and provides guidance for protocol design based on our measurements. The key question is "can we run new transport protocols for the Internet over UDP?" We find that the answer is largely "yes": UDP works on most networks, and impairments are generally confined to access networks. This allows relatively simple fallback strategies to work around it. Our answer is based on a twofold methodology. First, we use the RIPE Atlas platform to basically check UDP connectivity and first-packet latency. Second, we deploy copycat, a new tool for comparing TCP loss, latency, and throughput with UDP by generating TCP-shaped traffic with UDP headers

Using UDP for Internet Transport Evolution

The increasing use of middleboxes (e.g., NATs, firewalls) in the Internet has made it harder and harder to deploy new transport or higher layer protocols, or even extensions to existing ones. Current work to address this Internet transport ossification has led to renewed interest in UDP as an encapsulation for making novel transport protocols deployable in the Internet. Examples include Google's QUIC and the WebRTC data channel. The common assumption made by these approaches is that encapsulation over UDP works in the present Internet. This paper presents a measurement study to examine this assumption, and provides guidance for protocol design based on our measurements. The key question is "can we run new transport protocols for the Internet over UDP?" We find that the answer is largely "yes": UDP works on most networks, and impairments are generally confined to access networks. This allows relatively simple fallback strategies to work around it. Our answer is based on a twofold methodology. First, we use the RIPE Atlas platform to basically check UDP connectivity and first-packet latency. Second, we deploy copycat, a new tool for comparing TCP loss, latency, and throughput with UDP by generating TCP-shaped traffic with UDP headers

TCPLS: Modern Transport Services with TCP and TLS

peer reviewedTCP and TLS are among the essential protocols in today's Internet. TCP ensures reliable data delivery while TLS secures the data transfer. Although they are very often used together, they have been designed independently following the Internet layered model. This paper demonstrates the various benefits that a closer integration between TCP and TLS would bring. By leveraging the extensible TLS 1.3 records, we combine TCP and TLS into TCPLS to build modern transport services such as multiplexing, connection migration, stream steering, and bandwidth aggregation. These services do not modify the TCP wire format and are resistant to middleboxes. TCPLS offers a powerful API enabling applications to precisely express the required transport services, ranging from a single-path single-stream connection to a multi-stream connection over several network paths, enabling choices between aggregated bandwidth and head-of-line blocking avoidance.Compared to MPTCP, our TCPLS prototype offers more control to the application and can be easily deployed as an extension to user-space TLS libraries, while being implemented at a low cost. Measurements demonstrate that it offers higher performance than existing QUIC libraries with a super set of transport services